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Offer/Answer Considerations for G723 Annex A and G729 Annex B 


Abstract 


This document provides the offer/answer considerations for the annexa 
parameter of G723 and the annexb parameter of G7/29, G729D, and G729E 
when the value of the annexa or annexb parameter does not match in 
the Session Description Protocol (SDP) offer and answer. 
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1. Introduction 
[RFC4856] describes the annexa parameter for G723 as follows: 
annexa: indicates that Annex A, voice activity detection, is used 
or preferred. Permissible values are "yes" and "no" (without the 


quotes); "yes" is implied if this parameter is omitted. 


Also, [RFC4856] describes the annexb parameter for G/29, G729D, and 
G729E as follows: 


annexb: indicates that Annex B, voice activity detection, is used 
or preferred. Permissible values are "yes" and "no" (without the 
quotes); "yes" is implied if this parameter is omitted. 


However, a problem arises when the value of the annexa or annexb 
parameter does not match in the SDP [RFC4566] offer and answer. 


For example, if the offer has G729 with annexb=yes and the answer has 
G729 with annexb=no, it can be interpreted in two different ways: 


O The offerer and answerer proceed as if G729 is negotiated with 
annexb=yes, or 


O The offerer and answerer proceed as if G729 is negotiated with 
annexb=no. 
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Since this is not clear in the existing specifications, various 
implementations have interpreted the offer/answer in their own ways, 
resulting in a different codec being chosen to call failure, when the 
parameter value does not match in the offer and answer. 


[RFC3264] requires SDP extensions that define new fmtp parameters to 
specify their proper interpretation in offer/answer. This document 
specifies the proper interpretation for the annexa and annexb 
parameters in offer/answer. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Offer/Answer Considerations 


The general objective of the offer/answer considerations is to make 
sure that if the offerer or answerer indicates it does not support 
Annex A or Annex B, then Annex A or Annex B is not used. 


3.1. Considerations for Use of Comfort Noise Frames 
[RFC3551] states that: 


Receivers MUST accept comfort noise frames if restriction of their 
use has not been signaled. The MIME registration for G729 in RFC 
3555 specifies a parameter that MAY be used with MIME or SDP to 
restrict the use of comfort noise frames. 


Hence, if the SDP offer or answer indicates that comfort noise is not 
supported, comfort noise frames MUST NOT be used. 


3.2. Offer/Answer Considerations for G723 Annex A 


When the offer or answer has G723 and the annexa parameter is absent, 
the offerer or answerer knows that it has implied the default 
"annexa=yes". This is because the annexa attribute is part of the 
original registration of audio/G723 [RFC4856]. All implementations 
that support G723 understand the annexa attribute. Hence, this case 
MUST be considered as if the offer or answer has G723 with 
annexa=yes. 


When the offer has G7/723 with annexa=yes and the answer has G723 with 


annexa=no, the offerer and answerer MUST proceed as if G723 is 
negotiated with annexa=no. 
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When the offer has G723 with annexa=no, after the offer/answer 
completion the offerer and answerer MUST proceed as if G723 is 
negotiated with annexa=no. 


When the offer has G723 with annexa=no, the reason for not 
mandating that the answer MUST have annexa=no for G723 is that 
there are implementations that omit the annexa parameter in 
answer. In such cases, the offerer and answerer proceed as if 
G723 is negotiated with annexa=no. 


When the offer has G7/723 with no annexa parameter and the answer has 
G723 with annexa=yes, the offerer and answerer MUST proceed as if 
G723 is negotiated with annexa=yes. 


3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex B, and 
G729E Annex B 


In this section, G729 represents any of G7/29 or G729D or G729E. 


When the offer or answer has G729 and the annexb parameter is absent, 
the offerer or answerer knows that it has implied the default 
"annexb=yes". This is because the annexb attribute is part of the 
original registration of audio/G729 [RFC4856]. All implementations 
that support G729 understand the annexb attribute. Hence, this case 
MUST be considered as if the offer or answer has G729 with 
annexb=yes. 


When the offer has G729 with annexb=yes and the answer has G729 with 
annexb=no, the offerer and answerer MUST proceed as if G729 is 
negotiated with annexb=no. 


When the offer has G729 with annexb=no, after the offer/answer 
completion the offerer and answerer MUST proceed as if G729 is 
negotiated with annexb=no. 


When the offer has G729 with annexb=no, the reason for not 
mandating that the answer MUST have annexb=no for G729 is that 
there are implementations that omit the annexb parameter in the 
answer. In such cases, the offerer and answerer proceed as if 
G729 is negotiated with annexb=no. 


When the offer has G729 with no annexb parameter and the answer has 
G729 with annexb=yes, the offerer and answerer MUST proceed as if 
G729 is negotiated with annexb=yes. 
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4. Examples 
4.1. Offer with G729 annexb=yes and Answer with G729 annexb=no 


[Offer with G729 annexb=yes] 


v=0 

o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 
s= 

c=IN IP4 host.atlanta.example.com 

t=0 0 


m=audio 49170 RTP/AVP 18 
a=rtpmap:18 G729/8000 
a=fmtp:18 annexb=yes 


[Answer with G729 annexb=no] 


v=0 

o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 
s= 

c=IN IP4 host.bangalore.example.com 

t=0 0 


m=audio 19140 RTP/AVP 18 
a=rtpmap:18 G729/8000 
a=fmtp:18 annexb=no 


In the above example, the offerer and answerer proceed as if G729 is 
negotiated with annexb=no. 


4.2. Offer with G729 annexb=yes and Answer with G729 and No annexb 
Parameter 


[Offer with G729 annexb=yes] 


v=0 

o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 
s= 

c=IN IP4 host.atlanta.example.com 

t=0 0 


m=audio 49170 RTP/AVP 18 
a=rtpmap:18 G729/8000 
a=fmtp:18 annexb=yes 
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[Answer with G729 and no annexb parameter] 


v=0 

o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 
s= 

c=IN IP4 host.bangalore.example.com 

t=0 0 


m=audio 19140 RTP/AVP 18 
a=rtpmap:18 G729/8000 


In the above example, the offerer and answerer proceed as if G729 is 
negotiated with annexb=yes. 


4.3. Offer with G729 and No annexb Parameter and Answer with G729 
annexb=no 


[Offer with G729 and no annexb parameter] 


v=0 

o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 
s= 

c=IN IP4 host.atlanta.example.com 

t=0 0 


m=audio 49170 RTP/AVP 18 
a=rtpmap:18 G729/8000 


[Answer with G729 annexb=no] 


v=0 

o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 
s= 

c=IN IP4 host.bangalore.example.com 

t=0 0 


m=audio 19140 RTP/AVP 18 
a=rtpmap:18 G729/8000 
a=fmtp:18 annexb=no 


In the above example, the offerer and answerer proceed as if G729 is 
negotiated with annexb=no. 


5. Security Considerations 
The guidelines described in [RFC6562] are to be followed for Use of 


Voice Activity Detection (i.e., Annex A or Annex B) with the Secure 
Real-time Transport Protocol (SRTP). 
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